A risk management system for securities

ABSTRACT

A method and system ( 100 ) for identifying, measuring and managing the risk associated with a portfolio of securities.

CONTINUATION, CONTINUATION IN PART AND CROSS REFERENCE TO RELATEDAPPLICATIONS

This application is a continuation of application Ser. No. 10/329,172filed Dec. 23, 2002 the disclosure of which is incorporated herein byreference and a continuation in part of application Ser. No. 09/688,983filed Oct. 17, 2000 the disclosure of which is incorporated herein byreference. The subject matter of this application is also related to thesubject matter of U.S. patent application Ser. No. 09/994,740 filed Nov.28, 2001, U.S. patent application Ser. No. 10/012,374 filed Dec. 12,2001, U.S. patent application Ser. No. 10/036,522 filed Jan. 7, 2002,U.S. patent application Ser. No. 10/747,471 filed Dec. 29, 2003, U.S.patent application Ser. No. 10/821,504 filed Apr. 9, 2004 and U.S.patent application Ser. No. 11/142,785 filed May 31, 2005 thedisclosures of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

This invention relates to the identification, measurement and managementof the risk associated with a portfolio of securities and the automateddevelopment and delivery of products and programs that help transfersaid risk for a plurality of customers.

Insurance and most financial services are generally delivered in amanner that is very cumbersome. A system that would enable financialservice firms to provide financial “products” like insurance,derivatives, foreign exchange, capital and credit tailored to thespecific situation on a “just-in-time” would clearly be beneficial.

One of the biggest problems with achieving this goal has been that therehas been no agreed upon method for analyzing risk, liquidity and foreignexchange requirements and for communicating that information tofinancial service firms. It is worth noting at this point that while XMLis widely touted as a panacea for inter-firm communication it is onlyuseful in establishing the language for the communication—not thesubstance of what is being communicated. To satisfy all the potentialproviders of financial services, the substance of the communicationregarding risk, liquidity and foreign exchange requirements would haveto overcome the limitations of traditional systems and xml.

In light of the preceding discussion, it is clear that it would bedesirable to have an automated, real time system that could identify thefull spectrum of risk transfer (and liquidity) needs for an securityportfolio in a way that that would allow financial service firms toprovide “just in time” and/or real time financial products and servicesin a manner that is customized to the exact needs of the customers usingthe system.

SUMMARY OF THE INVENTION

It is a general object described herein to provide a novel and usefulsystem for the identification, measurement and management of the riskassociated with a portfolio of securities and the automated developmentand delivery of products and programs that help transfer said risk.

The information regarding the risk transfer needs for each customerusing the system is continuously developed and communicated to theoperator of the system described herein (such as an insurance company orbank) that analyzes the information for each customer in order to:

1) Arrange swaps of risk, between customers with complementary,offsetting needs (for a fee);

2) Arrange for risk transfers for a larger fee in order to meet theneeds of each customer using the system and the profit goals (andreserve requirements) of the firm operating the system; and

3) Complete the swaps and risk transfers that have been arranged inaccordance with customer instructions.

To provide an integrated system for transferring risk, the systemdescribed herein goes on to analyze the information provided by eachenterprise and the financial status of firm operating the system(hereinafter, the system operator) to determine if standby credit linesand/or re-insurance are required. If either of these “back-up” (akacontingent) facilities for capital are required, then the appropriateamount of standby credit and/or reinsurance is determined by the systemdescribed herein.

By eliminating many of the gaps in information available to personnel inthe enterprise and the system, the system described herein enables thejust-in-time provision of financial service products and services suchas risk transfer that are tailored to the exact needs of the enterprise.The electronic linkage also eliminates the time lag that prevents manyfrom companies from obtaining the risk reduction products they need

BRIEF DESCRIPTION OF DRAWINGS

These and other objects, features and advantages described herein willbe more readily apparent from the following description of oneembodiment of the invention in which:

FIG. 1 is a block diagram showing the major processing steps describedherein;

FIG. 2 is a diagram showing the files or tables in the applicationdatabase (50) described herein that are utilized for data storage andretrieval during the processing in the innovative risk transfer system;

FIG. 3 is a block diagram of an implementation described herein;

FIG. 4 is a diagram showing the data windows that are used for receivinginformation from and transmitting information to the customer (20)during system processing;

FIG. 5, is block diagrams showing the sequence of steps in the presentinvention used for specifying system settings and for initializing andoperating the data bots that extract, aggregate, store and manipulateinformation utilized in system processing from: the basic financialsystem, advanced financial system, customers and external databases; and

FIG. 6 is a block diagram showing the sequence in steps in the presentinvention used in the collaborative, on-line development and delivery ofcustomized risk transfer programs.

DETAILED DESCRIPTION OF ONE EMBODIMENT

FIG. 1 provides an overview of the processing completed by the systemfor the collaborative, on-line development and delivery of customizedrisk transfer programs. In accordance with the present invention, anautomated method of and system (100) for collaborative, on-linedevelopment and delivery of customized risk transfer programs isprovided. Processing starts in this system (100) with the specificationof system settings and the initialization and activation of softwaredata “bots” (200) that extract, aggregate, manipulate and store theinternal data, external data and customer data used for completingsystem processing. The data from external databases is used to analyzegeneric event risks and prices on investments for the asset classes andcontingent liabilities specified by the system operator (21). In oneembodiment, a customer financial model is created in order to identifythe impact of the different elements of value, external factors andrisks on customer financial performance and value. However, any othermethod or system for developing this data could be used to the sameeffect. All data used in processing is extracted via a network (45) froma basic financial system database (5), an external database (25), anadvanced finance system database (30) and a customer database (35).These information extractions and aggregations may be influenced by asystem operator (21) through interaction with a user-interface portionof the application software (700) that mediates the display,transmission and receipt of all information to and from browser software(800) such as the Microsoft Internet Explorer or Netscape Navigator inan access device (90) such as a phone or personal computer that thecustomer (20) or system operator interact with. While only one basicfinancial system database (5), external database (25), advanced financesystem database (30) and customer database (35) is shown in FIG. 1, itis to be understood that the system (100) can extract data from anunlimited number of databases and customers via the network (45). Italso to be understood that the customer (20) and the system operator(21) can operate separate access devices (90). It should also beunderstood that it is possible to complete a bulk extraction of datafrom each database (5, 25, 30 and 35) via the network (45) using dataextraction applications before initializing the data bots. The dataextracted in bulk could be stored in a single datamart or data warehousewhere the data bots could operate on the aggregated data.

All extracted information is stored in a file or table (hereinafter,table) within an application database (50) as shown in FIG. 2. Theapplication database (50) contains tables for storing input, extractedinformation and system calculations including an xml profile table(140), a bot date table (141), a customer table (142), a risk productstable (143), a swaps table (144), a customer profile table (145), anexchange payout history table (146), an generic risk table (147), aliability scenario table (148), an asset position table (149), anexternal database table (150), an asset forecasts table (151), an assetcorrelation table (152), an scenario table (153), an exchange simulationtable (154), a contingent capital table (155), an optimal exchange mixtable (156) and an exchange premium history table (157) a systemsettings table (158), a metadata mapping table (159), a conversion rulestable (160), a basic financial system table (161) and an advancedfinance system table (162). Other combinations of tables and files canbe used to the same effect. The application database (50) can optionallyexist on a hard drive, a datamart, data warehouse or departmentalwarehouse. The system described herein has the ability to accept andstore supplemental or primary data directly from user input, a datawarehouse or other electronic files in addition to receiving data fromthe customer databases described previously.

As shown in FIG. 3, one embodiment described herein is a computer system(100) illustratively comprised of a user-interface personal computer(110) connected to an application-server personal computer (120) via anetwork (45). The application server personal computer (120) is in turnconnected via the network (45) to a database-server personal computer(130). The user interface personal computer (110) is also connected viathe network (45) to an internet browser appliance (90) that containsbrowser software (800) such as Microsoft Internet Explorer or NetscapeNavigator.

The database-server personal computer (130) has a read/write randomaccess memory (131), a hard drive (132) for storage of the applicationdatabase (50), a keyboard (133), a communications bus card containingall required adapters and bridges (134), a display (135), a mouse (136)and a CPU (137).

The application-server personal computer (120) has a read/write randomaccess memory (121), a hard drive (122) for storage of thenon-user-interface portion of the enterprise portion of the applicationsoftware (200 and 300) described herein, a keyboard (123), acommunications bus containing all required adapters and bridges (124), adisplay (125), a mouse (126), a CPU (127) and a printer (128). Whileonly one client personal computer is shown in FIG. 3, it is to beunderstood that the application-server personal computer (120) can benetworked to fifty or more client personal computers (110) via thenetwork (45). The application-server personal computer (120) can also benetworked to fifty or more server, personal computers (130) via thenetwork (45). It is to be understood that the diagram of FIG. 3 ismerely illustrative of one embodiment described herein as the system(100) and application software (200, 300 and 700) could reside on asingle computer or any number of computers that are linked togetherusing a network. In a similar manner the system operator (21) and/or thecustomer (20) could interface directly with one or more of the computersin the system (100) instead of using an access device (90) with abrowser (800) as described in this embodiment.

The user-interface personal computer (110) has a read/write randomaccess memory (111), a hard drive (112) for storage of a clientdata-base (49) and the user-interface portion of the applicationsoftware (700), a keyboard (113), a communications bus containing allrequired adapters and bridges (114), a display (115), a mouse (116), aCPU (117) and a printer (118).

The application software (200, 300 and 700) controls the performance ofthe central processing unit (127) as it completes the calculations usedto support the collaborative development and implementation of a risktransfer program. In the embodiment illustrated herein, the applicationsoftware program (200, 300 and 700) is written in a combination of C++and Visual Basic® although other languages can be used to the sameeffect. The application software (200, 300 and 700) can use StructuredQuery Language (SQL) for extracting data from the different databases(5, 25, 30 and 35). The customer (20) and system operator (21) canoptionally interact with the user-interface portion of the applicationsoftware (700) using the browser software (800) in the browser appliance(90) to provide information to the application software (200, 300 and700) for use in determining which data will be extracted and transferredto the application database (50) by the data bots.

User input is initially saved to the client database (49) before beingtransmitted to the communication bus card (124) and on to the hard drive(122) of the application-server computer via the network (45). Followingthe program instructions of the application software, the centralprocessing unit (127) accesses the extracted data and user input byretrieving it from the hard drive (122) using the random access memory(121) as computation workspace in a manner that is well known.

The computers (110, 120 and 130) shown in FIG. 3 illustratively are IBMPCs or clones or any of the more powerful computers (such as mainframecomputers) or workstations that are widely available. Typical memoryconfigurations for client personal computers (110) used with the presentinvention should include at least 512 megabytes of semiconductor randomaccess memory (111) and at least a 100 gigabyte hard drive (112).Typical memory configurations for the application-server personalcomputer (120) used with the present invention should include at least2056 megabytes of semiconductor random access memory (121) and at leasta 250 gigabyte hard drive (122). Typical memory configurations for thedatabase-server personal computer (130) used with the present inventionshould include at least 4112 megabytes of semiconductor random accessmemory (131) and at least a 500 gigabyte hard drive (132).

Using the system described above, customer financial data is analyzedbefore a comprehensive risk management program is developed andimplemented for each customer. The risk reduction program development iscompleted in two stages. As shown in FIG. 5 the first stage ofprocessing (block 200 from FIG. 1) programs bots to continually extract,aggregate, manipulate and store the data from user input, externaldatabases (25) and customer databases (30). Bots are independentcomponents of the application that have specific tasks to perform. Asshown in FIG. 6 the second stage of processing (block 300 from FIG. 1)analyzes customer risk profiles, determines the optimal risk transferprogram for each customer, sets prices and communicates with eachcustomer as in order to complete risk reduction program development andimplementation. The processing described in this application foridentifying the optimal risk transfer program for each customer canoptionally be completed at the enterprise level (as shown in the parentapplication Ser. No. 09/688,983) before data is transmitted to thesystem of the present invention.

System Settings and Data Bots

The flow diagrams in FIG. 5 details the processing that is completed bythe portion of the application software (200) that obtains systemssettings from the system operator (21) before extracting, aggregatingand storing the information used for system operation from a basicfinancial system database, an external database (25), and advancedfinance system database (30) and a customer database (35).

System processing starts in a block 201, FIG. 5A, which immediatelypasses processing to a software block 202. The software in block 202prompts the system operator (21) via the system settings data window(701) to provide system setting information. The system settinginformation entered by the system operator (21) is transmitted via thenetwork (45) back to the application server (120) where it is stored inthe system settings table (158) in the application database (50) in amanner that is well known. The specific inputs the system operator (21)is asked to provide at this point in processing are shown in Table 1.TABLE 1 1. Continuous run, if yes, frequency? (hourly, daily, weekly,monthly or quarterly) 2. Account structure hierarchy 3. Metadatastandard (XML, MS OIM, MDC) 4. Location of account structure 5. Locationof basic financial system database and metadata 6. Location of advancedfinance system database and metadata 7. Location of customer database(s)and metadata 8. Location of external database(s) and metadata 9. Basecurrency 10. Asset classes of interest 11. Contingent capitalalternatives 12. Default missing data procedure 13. Maximum time to waitfor user input 14. Confidence interval for risk reduction programsThe software in block 202 uses the current system date to determine thetime periods (months) that require data to complete the development ofrisk transfer programs. After the date range is calculated, it is storedin the system settings table (158). In one embodiment data is obtainedfor the three year period before and the three year forecast periodafter the current date. The system operator (21) also has the option ofspecifying the data periods that will be used for completing systemcalculations.

After the storage of system setting data is complete, processingadvances to a software block 203. The software in block 203 prompts thesystem operator (21) via the metadata and conversion rules window (702)to map metadata using the standard previously specified by the systemoperator (21) (XML, Microsoft Open Information Model or the MetadataCoalitions specification) from the basic financial system database (5),the external database (25), the advanced financial system database (30)and the customer database (35) to the enterprise hierarchy stored in thesystem settings table (158) and to the pre-specified fields in themetadata mapping table (159). Pre-specified fields in the metadatamapping table include, the revenue, expense and capital components andsub-components for the exchange and pre-specified fields for expectedvalue drivers. Because the bulk of the information being extracted isfinancial information, the metadata mapping often takes the form ofspecifying the account number ranges that correspond to the differentfields in the metadata mapping table (159). Table 2 shows the baseaccount number structure that the account numbers in the other systemsmust align with. For example, using the structure shown below, therevenue component for the enterprise could be specified as enterprise01, any department number, accounts 400 to 499 (the revenue accountrange) with any sub-account. TABLE 2 Account Number 01 - 902 (any) -477- 86 (any) Segment Enterprise Department Account Sub-account SubgroupWorkstation Marketing Revenue Singapore Position 4 3 2 1As part of the metadata mapping process, any database fields that arenot mapped to pre-specified fields are defined by the system operator(21) as component of value, elements of value or non-relevant attributesand “mapped” in the metadata mapping table (159) to the correspondingfields in each database in a manner identical to that described abovefor the pre-specified fields. After all fields have been mapped to themetadata mapping table (159), the software in block 203 prompts thesystem operator (21) via the metadata and conversion rules window (702)to provide conversion rules for each metadata field for each datasource. Conversion rules will include information regarding currencyconversions and conversion for units of measure that may be required toaccurately and consistently analyze the data. The inputs from the systemoperator (21) regarding conversion rules are stored in the conversionrules table (160) in the application database (50). When conversionrules have been stored for all fields from every data source, thenprocessing advances to a software block 204.

The software in block 204 checks the bot date table (141) anddeactivates any basic financial system data bots with creation datesbefore the current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160), the asset position table (149) and the basic financialsystem table (161). The software in block 204 then initializes data botsfor each field in the metadata mapping table (159) that mapped to thebasic financial system database (5) in accordance with the frequencyspecified by system operator (21) in the system settings table (158).Bots are independent components of the application that have specifictasks to perform. In the case of data acquisition bots, their tasks areto extract and convert data from a specified source and then store it ina specified location. Each data bot initialized by software block 204will store its data in the asset position table (149) or the basicfinancial system table (161). Every data acquisition bot for every datasource contains the information shown in Table 3. TABLE 3 1. Unique IDnumber (based on date, hour, minute, second of creation) 2. The datasource location 3. Mapping information 4. Timing of extraction 5.Conversion rules (if any) 6. Storage Location (to allow for tracking ofsource and destination events) 7. Creation date (date, hour, minute,second)After the software in block 204 initializes all the bots for the basicfinancial system database, the bots extract and convert data inaccordance with their preprogrammed instructions in accordance with thefrequency specified by system operator (21) in the system settings table(158). As each bot extracts and converts data from the basic financialsystem database (5), processing advances to a software block 209 beforethe bot completes data storage. The software in block 209 checks thebasic financial system metadata to see if all data for all fields havebeen extracted and that there are metadata assignments for all extracteddata. If the software in block 209 finds no unmapped data fields, thenthe extracted, converted data are stored in the asset position table(149) or the basic financial system table (161). Alternatively, if thereare unmapped data fields, then processing advances to a block 211. Thesoftware in block 211 prompts the system operator (21) via the metadataand conversion rules window (702) to provide metadata and conversionrules for each new field. The information regarding the new metadata andconversion rules is stored in the metadata mapping table (159) andconversion rules table (160) while the extracted, converted data arestored in the asset position table (149) or the basic financial systemtable (161). It is worth noting at this point that the activation andoperation of bots where all the fields have been mapped to theapplication database (50) continues. Only bots with unmapped fields“wait” for user input before completing data storage. The new metadataand conversion rule information will be used the next time bots areinitialized in accordance with the frequency established by the systemoperator (21). In either event, system processing passes on to asoftware block 221.

The software in block 221 checks the bot date table (141) anddeactivates any external database data bots with creation dates beforethe current system date and retrieves information from the generic risktable (147), external database table (150), system settings table (158),metadata mapping table (159) and conversion rules table (160). Thesoftware in block 221 then initializes data bots for each field in themetadata mapping table (159) that mapped to the external database (25)in accordance with the frequency specified by system operator (21) inthe system settings table (158). Bots are independent components of theapplication that have specific tasks to perform. In the case of dataacquisition bots, their tasks are to extract and convert data from aspecified source and then store it in a specified location. Each databot initialized by software block 221 will store its data in the genericrisk table (147) or the external database table (150). After thesoftware in block 221 initializes all the bots for the advanced financesystem database, the bots extract and convert data in accordance withtheir preprogrammed instructions in accordance with the frequencyspecified by system operator (21) in the system settings table (158). Aseach bot extracts and converts data from the external database (25),processing advances to a software block 209 before the bot completesdata storage. The software in block 209 checks the advanced financesystem metadata to see if all data for all fields have been extractedand that there are metadata assignments for all extracted data. If thesoftware in block 209 finds no unmapped data fields, then the extracted,converted data are stored in the generic risk table (147) or externaldatabase table (150). Alternatively, if there are unmapped data fields,then processing advances to a block 211. The software in block 211prompts the system operator (21) via the metadata and conversion ruleswindow (702) to provide metadata and conversion rules for each newfield. The information regarding the new metadata and conversion rulesis stored in the metadata mapping table (159) and conversion rules table(160) while the extracted, converted data are stored in the generic risktable (147) or external database table (150). It is worth noting at thispoint that the activation and operation of bots where all the fieldshave been mapped to the application database (50) continues. Only botswith unmapped fields “wait” for user input before completing datastorage. The new metadata and conversion rule information will be usedthe next time bots are initialized in accordance with the frequencyestablished by the system operator (21). In either event, systemprocessing passes on to a software block 225.

The software in block 225 checks the bot date table (141) anddeactivates any advanced finance system data bots with creation datesbefore the current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160) and advanced finance system table (162). The software inblock 225 then initializes data bots for each field in the metadatamapping table (159) that mapped to the advanced finance system database(30) in accordance with the frequency specified by system operator (21)in the system settings table (158). Bots are independent components ofthe application that have specific tasks to perform. In the case of dataacquisition bots, their tasks are to extract and convert data from aspecified source and then store it in a specified location. Each databot initialized by software block 225 will store its data in the assetposition table (149) or the advanced finance system table (162). Afterthe software in block 225 initializes all the bots for the advancedfinance system database, the bots extract and convert data in accordancewith their preprogrammed instructions in accordance with the frequencyspecified by system operator (21) in the system settings table (158). Aseach bot extracts and converts data from the basic financial systemdatabase (5), processing advances to a software block 209 before the botcompletes data storage. The software in block 209 checks the advancedfinance system metadata to see if all data for all fields have beenextracted and that there are metadata assignments for all extracteddata. If the software in block 209 finds no unmapped data fields, thenthe extracted, converted data are stored in the asset position table(149) or the advanced finance system table (162). Alternatively, ifthere are unmapped data fields, then processing advances to a block 211.The software in block 211 prompts the system operator (21) via themetadata and conversion rules window (702) to provide metadata andconversion rules for each new field. The information regarding the newmetadata and conversion rules is stored in the metadata mapping table(159) and conversion rules table (160) while the extracted, converteddata are stored in asset position table (149) or the advanced financesystem table (162). It is worth noting at this point that the activationand operation of bots where all the fields have been mapped to theapplication database (50) continues. Only bots with unmapped fields“wait” for user input before completing data storage. The new metadataand conversion rule information will be used the next time bots areinitialized in accordance with the frequency established by the systemoperator (21). In either event, system processing passes on to asoftware block 226.

The software in block 226 checks the bot date table (141) anddeactivates any customer database data bots with creation dates beforethe current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160) and customer table (142). The software in block 226 theninitializes data bots for each field in the metadata mapping table (159)that mapped to the customer database (35) in accordance with thefrequency specified by system operator (21) in the system settings table(158). Bots are independent components of the application that havespecific tasks to perform. In the case of data acquisition bots, theirtasks are to extract and convert data from a specified source and thenstore it in a specified location. Each data bot initialized by softwareblock 226 will extract the model of customer financial performance byelement of value, factor and risk and the confidence interval for riskreduction programs specified by the customer. The bot will then storethis data in the customer profile table (145). After the software inblock 226 initializes all the bots for the advanced finance systemdatabase, the bots extract and convert data in accordance with theirpreprogrammed instructions in accordance with the frequency specified bysystem operator (21) in the system settings table (158). As each botextracts and converts data from the customer database (25), processingadvances to a software block 209 before the bot completes data storage.The software in block 209 checks the advanced finance system metadata tosee if all data for all fields have been extracted and that there aremetadata assignments for all extracted data. If the software in block209 finds no unmapped data fields, then the extracted, converted dataare stored in the customer profile table (145). Alternatively, if thereare unmapped data fields, then processing advances to a block 211. Thesoftware in block 211 prompts the system operator (21) via the metadataand conversion rules window (702) to provide metadata and conversionrules for each new field. The information regarding the new metadata andconversion rules is stored in the metadata mapping table (159) andconversion rules table (160) while the extracted, converted data arestored in the customer profile table (145). It is worth noting at thispoint that the activation and operation of bots where all the fieldshave been mapped to the application database (50) continues. Only botswith unmapped fields “wait” for user input before completing datastorage. The new metadata and conversion rule information will be usedthe next time bots are initialized in accordance with the frequencyestablished by the system operator (21). In either event, systemprocessing passes on to software block 301.

Risk Exchange

The flow diagram in FIG. 6 details the processing that is completed bythe portion of the application software (300) that analyzes informationfrom a number of customers and arranges for risk “swaps” and/or the saleof risk transfer products to each customer at a price that meets theprofit goals and reserve requirements of the company operating the riskexchange. The description below will follow the processing andactivities of the system described herein when one new customer profileis transmitted to the exchange.

System processing in this portion of the application software (300)begins in a block 302. The software in block 302 checks the bot datetable (141) and deactivates any transfer bots with creation dates beforethe current system date for the customer transmitting data to theexchange. The software in block 302 then retrieves the information fromthe xml profile table (140), the customer table (142), the risk productstable (143), the swaps table (144) and the customer profile table (145)in order to initialize transfer bots for the customer transmitting asummary profile to the exchange.

Bots are independent components of the application that have specifictasks to perform. In the case of transfer bots, their primary tasks areto identify swaps, existing product and new products that can be used tosatisfy the risk transfer needs of the customer transmitting data to theexchange. For example, if one customer has a significant risk from oilprices dropping (a heating oil company, for example) and anothercustomer faces a significant risk when oil prices rise (a truckingcompany, for example), then the transfer bot will identify theoffsetting risk factors and record a swap. If the risk transfer can becompleted by both an existing risk transfer product and a swap, thenpreference is given to the swap. Every transfer bot contains theinformation shown in Table 4. TABLE 4 1. Unique ID number (based ondate, hour, minute, second of creation) 2. Creation date (date, hour,minute, second) 3. Mapping information 4. Storage location 5. Riskfactor 6. Type: Swap, existing product or (potential) new product 7.Amount(s) 8. Date(s) 9. Customer 1 (for swaps only) . . . to 9 + n.Customer n (for swaps only)After the transfer bot identifies the swaps, existing products and newproducts that will satisfy the needs of the enterprise for risk transferthe results are saved to the application database (50). Information onswaps is saved on the swaps table (144) and the customer profile table(145) and information on new products is saved in the risk productstable (143) without a price. The price for new products will beestablished later in the processing. After data storage is complete,processing advances to a software block 305.

The software in block 305 checks the bot date table (141) anddeactivates any liability scenario bots with creation dates before thecurrent system date. The software in block 305 then retrieves theinformation from the xml profile table (140), the customer table (142),the risk products table (143), the swaps table (144), the customerprofile table (145), the exchange payout history table (146), thegeneric risk table (147) and the exchange premium history table (156) inorder to initialize new liability scenario bots. Bots are independentcomponents of the application that have specific tasks to perform. Inthe case of liability scenario bots, their primary tasks are to create aseries of scenarios estimating the net payout (premiums minus payout=netpayout) associated the risks that may be transferred via swaps orinsurance from all customers. There are two types of scenarios developedat this stage of processing, normal scenarios and extreme scenarios. Thescenarios are developed by combining the information and statistics fromsummary profiles transmitted by the customers of the exchange with theexchange payout history, the exchange premium history and generic riskinformation obtained from the external database (25). Every liabilityscenario bot activated in this block contains the information shown inTable 5. TABLE 5 1. Unique ID number (based on date, hour, minute,second of creation) 2. Creation date (date, hour, minute, second) 3.Mapping information 4. Storage location 5. Type: extreme or normalAfter the liability scenario bots are initialized, they retrieve therequired information from the xml profile table (140), the customertable (142), the risk products table (143), the swaps table (144), thecustomer profile table (145), the exchange payout history table (146),the generic risk table (147), the external database table (150), thebasic financial system table (161), the advanced finance system table(162) and the exchange premium history (156) before generating a seriesof net payout scenarios that are appropriate for the type of analysisbeing completed—extreme or normal. The bot saves the scenarios in theliability scenario table (148) in the application database (50) andprocessing advances to a block 309.

The software in block 309 continually completes analyses similar tothose completed by the analysis bots in the enterprise portion of theparent application Ser. No. 09/688,983. The software in this block usesthe publicly available information stored in the external database table(150) to complete the analyses shown in Table 6 for each equityinvestment listed in the asset position table (149) and described indata obtained from the external database (25). TABLE 6 1. Identifymarket value factors causing changes in the equity market price; 2.Forecast the value of the current operation for the company as afunction of the causal factors identified in 1 and prior performanceusing forecasting method for revenue, expense and capital change similarto that described in related U.S. Pat. No. 5,615,109; 3. Forecast theallocation of industry real options to the company on the basis ofrelative causal intangible element of value strength using forecastingmethod similar to that described in related U.S. Pat. No. 5,615,109; and4. Forecast the income (dividends) provided by the equity as a functionof the causal factors identified in 1 and prior performanceThe results of the first three forecasts (items 2, 3 and 4 from Table 6)are saved in the asset forecasts table (151) in the application database(50) and the market value factors (item 1 from Table 6) are saved withthe appropriate equity in the asset position table (149). The softwarein this block uses the publicly available information stored in theexternal database table (150) to complete the analyses shown in Table 6for each income generating investments (i.e. bonds or real estate)listed in the asset position table (149) and described in data obtainedfrom the external database (25). The software in block 309 then analyzesthe covariance between the causal factors for each of the assets todetermine the covariance between these assets under both normal andextreme conditions. The results of these analyses are then stored in theasset correlation table (152) before processing advances to a block 310.

The software in block 310 checks the bot date table (141) anddeactivates any scenario bots with creation dates before the currentsystem date. The software in block 310 then retrieves the informationfrom the asset position table (149), the external database table (150)and the asset correlation table (152) in order to initialize thescenario bots. Bots are independent components of the application thathave specific tasks to perform. In the case of scenario bots, theirprimary task is to identify likely scenarios for the evolution of thecausal market value factors. The scenario bots use information from theexternal databases to obtain forecasts for individual causal factorsbefore using the covariance information stored in the asset correlationtable (152) to develop scenarios for the other causal factors undernormal and extreme conditions. Every scenario bot activated in thisblock contains the information shown in Table 7. TABLE 7 1. Unique IDnumber (based on date, hour, minute, second of creation) 2. Creationdate (date, hour, minute, second) 3. Mapping information 4. Storagelocation 5. Type: Normal or extremeAfter the scenario bots are initialized, they retrieve the requiredinformation and develop a variety of normal and extreme scenarios asdescribed previously. After the scenario bots complete theircalculations they save the resulting scenarios in the scenario table(153) in the application database (50) and processing advances to ablock 311.

The software in block 311 checks the bot date table (141) anddeactivates any net capital scenario bots with creation dates before thecurrent system date. The software in block 311 then retrieves theinformation from the liability scenario table (148), and the scenariotable (153) in order to initialize net capital scenarios bots. Bots areindependent components of the application that have specific tasks toperform. In the case of net capital scenario bots, their primary task isto run four different types of simulations for the exchange. The netcapital scenario bots run Monte Carlo simulations of the exchangefinancial performance using the two types of scenarios generated by theasset and liability scenario bots—normal and extreme. The net capitalscenario bots also run an unconstrained genetic algorithm simulationthat evolves to the most negative scenario and simulations specified byregulatory agencies. Every net capital scenario bot activated in thisblock contains the information shown in Table 8. TABLE 8 1. Unique IDnumber (based on date, hour, minute, second of creation) 2. Creationdate (date, hour, minute, second) 3. Mapping information 4. Storagelocation 5. Type: Normal, extreme, genetic algorithm or complianceAfter the net capital scenario bots are initialized, they retrieve therequired information and simulate the financial performance of the riskexchange under the different scenarios. After the net capital scenarioscomplete their calculations, the resulting forecasts are saved in theexchange simulation table (154) in the application database (50) andprocessing advances to a block 312.

The software in block 312 checks the bot date table (141) anddeactivates any asset optimization bots with creation dates before thecurrent system date. The software in block 312 then retrieves theinformation from the asset position table (149), the external databasetable (150), the asset forecasts table (151), the asset correlationtable (152), the scenario table (153), the exchange simulation table(154) and the advanced finance systems table (162) in order toinitialize asset optimization bots. Bots are independent components ofthe application that have specific tasks to perform. In the case ofasset optimization bots, their primary task is to determine the optimalmix of assets and contingent capital purchases (purchase reinsuranceand/or other contingent capital purchases, etc.) for the exchange undereach scenario using a linear programming optimization algorithm that isconstrained by any limitations imposed by regulatory requirements. Amulti-criteria optimization is also run at this stage to determine thebest mix for maximizing value under combined normal and extremescenarios. A penalty function for asset liability mismatch can be addedin order to minimize the difference between asset and liability lives.Other optimization algorithms can be used at this point to achieve thesame result. Every asset optimization bot activated in this blockcontains the information shown in Table 9. TABLE 9 1. Unique ID number(based on date, hour, minute, second of creation) 2. Creation date(date, hour, minute, second) 3. Mapping information 4. Storage location5. Type: Normal, extreme or combinedAfter the asset optimization bots complete their analyses, the resultingasset and contingent capital mix for each set of scenarios and thecombined analysis is saved in the optimal exchange mix table (156) inthe application database (50) and the revised simulations are saved inthe exchange simulation table (154) before processing passes to asoftware block 313.

The software in block 313 prepares and displays the optimal mix of assetpurchases, asset sales and contingent capital purchases for the normal,extreme and combined scenario analysis using the optimal mix reviewwindow (703). The optimal mix for the normal and extreme scenarios aredetermined by calculating the weighted average sum of the differentscenarios where the weighting is determined by the relative likelihoodof the scenario. The display identifies the optimal mix from thecombined analysis as the recommended solution for exchange valuemaximization. At this point, the system operator (21) is given theoption of:

1) Editing (adding or deleting products and activities) from therecommended solution;

2) Selecting the optimal mix from the normal scenarios;

3) Selecting and then editing the optimal mix from the normal scenarios;

4) Selecting the optimal mix from the extreme scenarios;

5) Selecting and then editing the optimal mix from the extremescenarios; or

6) Leaving the default choice in place.

After the system operator (21) has finished the review and the optionaledit of the selected mix, any changes are saved in the optimal exchangemix table (156) in the application database (50) before processingadvances to a software block 314.

The software in block 314 compares the new optimal mix to the existingasset position stored in the asset position table (149) and orders aregenerated to purchase assets, sell assets and/or purchase contingentcapital in order to bring the current asset position in line with thenew optimal mix. These orders are then transmitted via a network (45) toother institutions and exchanges on the Internet (40). When the orderconfirmations are received, the asset position table (149) is updatedwith the new information and processing advances to a block 315. It isworth noting at this point that the processing described for theprevious blocks in this section (302, 305, 109, 310, 311, 312, 313 and314) could also be used to manage an investment portfolio on a standalone basis.

The software in block 315 prepares and displays the proposed prices forthe risk transfer products and the swaps that are going to be offered tothe customer using the price review window (704). The list prices fromthe risk products table (143) are used for the existing risk products.Pricing for swaps are calculated by marking up the cost of the swap by astandard percentage. The software in block 315 marks up the calculatedbreakeven price for any new risk transfer products that were proposed bythe bots in block 302. At this point, the system operator (21) is giventhe option of:

1) Editing the recommended prices for any and all of the risktransfers—swaps, existing products and new products;

2) Accepting the recommended prices; or

3) Removing some of swaps and/or risk transfer products from the list.

After the system operator (21) completes the review, all price changesand the prices for any new risk transfer products are saved in the riskproducts table (143) before processing advances to a block 316.

The software in block 316 continually runs an analysis to define theoptimal risk reduction strategy for the normal and extreme scenarios foreach customer. It does this by first retrieving data from the xmlprofile table (140), the customer table (142), the risk products table(143), the swaps table (144), the customer profile table (145), theexchange payout history table (146), the generic risk table (147), theexternal database table (150) and the scenario table (153)—theinformation required to initialize the optimization algorithm. Thesoftware in the block uses a linear program that uses the financialmodel for each customer under the range of conditions expected for eachscenario to determine the optimal risk transfer program (swaps,derivative purchases, insurance purchases, etc.) within the specifiedconfidence interval (the confidence interval specified by the systemoperator (21) is used if the customer has not specified a confidenceinterval). A multi criteria optimization determines the best mix forreducing the risk under a combined normal and extreme scenario. Otheroptimization algorithms and simulations can be used at this point to thesame effect. The optimizations consider the effect of changes in thecost of capital on the optimal risk transfer solution. The resulting mixof product purchases and swaps for each scenario (normal and extreme)and the combined analysis is saved in the customer profile table (145)in the application database (50) before processing passes to a softwareblock 317. The shadow prices from these optimizations are also stored inthe risk products table (143) for use in identifying new risk reductionproducts that the system operator (21) may choose to offer at a laterdate. This information can also be used to modify pricing by customer.

The software in block 317 uses the customer interface window (705) todisplay the information regarding the optimal risk transfer program forthe customer and the pricing for the products and swaps that will beused to transfer the risks identified in the optimal risk transferprogram. This information could optionally be transmitted to thecustomer in a summary xml format that is similar to the one initiallytransmitted to the exchange by the customer. The customer (20) canreject, edit and/or accept the proposed mix of products and swaps thatare displayed. The software in block 317 accepts and confirms orders,updates the information contained in the risk products table (143), theswaps table (144), the customer profile table (145) and the exchangepremium history table (157) to reflect the accepted and confirmedorders. The software in block 317 also accepts input from the customer(20) regarding any new losses that the customer may have experienced.The software in block 317 verifies the loss is for an insured risk,updates the customer profile table (145), updates the exchange payouthistory table (146) and arranges for payment of the claim in a mannerthat is well known. This processing is continues until the customer (20)indicates that the session is complete. System processing advances to asoftware block 318.

The software in block 318 checks the system settings table (158) todetermine if the system (100) is operating in continuous mode. If thesystem is operating in a continuous mode, then processing returns toblock 205 and the processing described above is repeated. Alternatively,if the system is not operating in continuous mode, then processingadvances to a software block 320 and stops.

Thus, the reader will see that the system and method described abovetransforms extracted transaction data, corporate information,information from external databases and information from the internetinto detailed risk analyses and risk transfer programs specificallytailored to each customer using the system. The level of detail, breadthand speed of the risk analysis allows customers and managers of thesystem to manage their risks in an fashion that is superior to themethod currently available to users of existing risk analysis systemsand traditional insurance products.

Because the profiles used in the system (100) provide a comprehensivepicture of the financial status of the companies transferring riskthrough the exchange, the system and method described herein can be usedwith essentially no modifications to provide an online transfer systemfor:

1. Foreign exchange;

2. Capital (aka liquidity);

3. Any combination of foreign exchange, capital and risk.

The system described herein could be used to manage transfers ofownership rights alone or in combination with foreign exchange,liquidity and risk.

While the above description contains many specificities, these shouldnot be construed as limitations on the scope of the invention, butrather as an exemplification of one embodiment thereof. Accordingly, thescope of the invention should be determined not by the embodimentillustrated, but by the appended claims and their legal equivalents.

1. A risk method, comprising: aggregating data related to a securityportfolio, identifying a plurality of risks by source that may have animpact on a financial performance of said portfolio by analyzing atleast a portion of said data, and completing a series of tasks relatedto said risks where the tasks are selected from the group consisting ofmeasuring said risks, identifying an optimal set of risk transfertransactions for each portfolio, completing an optimal set of risktransfer transactions for each portfolio, reporting said risks andcombinations thereof where a plurality of risks further comprise eventrisks and risks selected from the group consisting of contingentliabilities, strategic risks, variability risks, volatility andcombinations thereof.
 2. The method of claim 1 wherein identifying anoptimal set of risk transfer transactions further comprise identifying aset of transactions selected from the group consisting of insurancepolicy transactions, swap transactions, derivative transactions,contingent capital transactions, security sales and combinationsthereof.
 3. The method of claim 1 wherein measuring a plurality ofidentified risks further comprises developing a plurality of scenariosselected from the group consisting of normal, extreme, regulatory andcombinations thereof for a security portfolio financial performance andsimulating the performance of the portfolio under each scenario in orderto measure the impact of each risk from the plurality of risks bysource.
 4. The method of claim 1 wherein identifying a plurality ofrisks by source further comprises identifying an external factor that isa source of one or more risks.
 5. The method of claim 4 wherein anexternal factor is selected from the group consisting of the ratio ofactual earnings to expected earnings, a commodity price, an inflationrate, a gross national product (gnp) growth rate, a market volatilitymeasure, volatility vs. industry average volatility, an interest rate,an interest rate change, an insider trading direction, an insidertrading level, a consumer confidence level an unemployment rate andcombinations thereof.
 6. The method of claim 1 wherein identifying aplurality of risks by source further comprises identifying an element ofvalue that is a source of one or more risks where an element of value isselected from the group consisting of alliances, brands, customers,customer relationships, employees, employee relationships,infrastructure, intellectual property, information technology,partnerships, processes, production equipment, vendors, vendorrelationships and combinations thereof.
 7. The method of claim 1 thatfurther comprises: obtaining a set of measured risks for a plurality ofcustomers, a set of regulatory requirements and a plurality ofperformance data for a risk transfer operation, generating a pluralityof scenarios for a risk transfer operation performance using theperformance data, regulatory requirements and customer risk data;identifying and displaying an optimal mode for risk transfer operationunder each scenario, and optionally implementing the optimal mode for achosen scenario in an automated fashion where implementing an optimalmode for the risk transfer operation includes taking actions selectedfrom the group consisting of changing one or more contingent capitalcontracts, purchasing one or more contingent capital contracts, changinga duration for one or more investments, changing an investment mix,adding one or more risk transfer products, changing one or more risktransfer product specification, changing one or more risk transferproduct prices, changing one or more reserve levels, completing aplurality of customer risk transfer transactions and combinationsthereof.
 8. A computer readable medium having sequences of instructionsstored therein, which when executed cause the processor in a computer toperform a risk method, comprising: aggregating data from a plurality ofmanagement systems for a portfolio of securities, developing a model ofportfolio performance by segment of value using said data; andquantifying a plurality of risks by source of risk that have an impacton the financial performance of said portfolio using said model wherethe segments of value are selected from the group consisting ofderivatives, investments and combinations thereof, and where the sourcesof risk are selected from the group consisting of a plurality ofelements of value, a plurality of external factors and combinationsthereof.
 9. The computer readable medium of claim 8 wherein the methodfurther comprises: completing a series of tasks related to a pluralityof quantified risks for a portfolio wherein said tasks are selected fromthe group consisting of identifying an optimal set of risk transfertransactions for the portfolio, completing an optimal set of risktransfer transactions for the portfolio, reporting said portfolio risksand combinations thereof
 10. The computer readable medium of claim 8wherein a plurality of risks further comprise event risks and risksselected from the group consisting of contingent liabilities, strategicrisks, variability risks, volatility and combinations thereof.
 11. Thecomputer readable medium of claim 8 wherein identifying an optimal setof risk transfer transactions further comprise identifying a set oftransactions selected from the group consisting of insurance policytransactions, swap transactions, derivative transactions, contingentcapital transactions, security sales and combinations thereof.
 12. Thecomputer readable medium of claim 8 wherein quantifying a plurality ofrisks further comprises developing a plurality of scenarios selectedfrom the group consisting of normal, extreme, regulatory andcombinations thereof for a portfolio of securities financial performanceand simulating the performance of the portfolio by segment of valueunder each scenario in order to measure the impact of each risk from theplurality of risks.
 13. The computer readable medium of claim 8 whereina plurality of external factors are selected from a group consisting ofthe ratio of actual earnings to expected earnings, a commodity price, aninflation rate, a gross national product (gnp) growth rate, a marketvolatility measure, volatility vs. industry average volatility, aninterest rate, an interest rate change, an insider trading direction, aninsider trading level, a consumer confidence level an unemployment rateand combinations thereof.
 14. The computer readable medium of claim 8wherein a plurality of elements of value are selected from the groupconsisting of is selected from the group consisting of alliances,brands, customers, customer relationships, employees, employeerelationships, infrastructure, intellectual property, informationtechnology, partnerships, processes, production equipment, vendors,vendor relationships and combinations thereof.
 15. A risk system,comprising: networked computers each with a processor having circuitryto execute instructions; a storage device available to each processorwith sequences of instructions stored therein, which when executed causethe processors to: aggregate data related to a security portfolio,identify a plurality of risks by source that may have an impact on afinancial performance of said portfolio by analyzing at least a portionof said data, and complete a series of tasks related to said risks wherethe tasks are selected from the group consisting of measuring saidrisks, identifying an optimal set of risk transfer transactions for eachportfolio, completing an optimal set of risk transfer transactions foreach portfolio, reporting said risks and combinations thereof where aplurality of risks further comprise event risks and risks selected fromthe group consisting of contingent liabilities, strategic risks,variability risks, volatility and combinations thereof.
 16. The systemof claim 15 wherein identifying an optimal set of risk transfertransactions further comprise identifying a set of transactions selectedfrom the group consisting of insurance policy transactions, swaptransactions, derivative transactions, contingent capital transactions,security sales and combinations thereof.
 17. The system of claim 15wherein measuring a plurality of identified risks further comprisesdeveloping a plurality of scenarios selected from the group consistingof normal, extreme, regulatory and combinations thereof for a securityportfolio financial performance and simulating the performance of theportfolio under each scenario in order to measure the impact of eachrisk from the plurality of risks by source.
 18. The system of claim 15wherein identifying a plurality of risks by source further comprisesidentifying an external factor that is a source of one or more risks.19. The system of claim 18 wherein an external factor is selected fromthe group consisting of the ratio of actual earnings to expectedearnings, a commodity price, an inflation rate, a gross national product(gnp) growth rate, a market volatility measure, volatility vs. industryaverage volatility, an interest rate, an interest rate change, aninsider trading direction, an insider trading level, a consumerconfidence level an unemployment rate and combinations thereof.
 20. Thesystem of claim 15 wherein identifying a plurality of risks by sourcefurther comprises identifying an element of value that is a source ofone or more risks where an element of value is selected from the groupconsisting of alliances, brands, customers, customer relationships,employees, employee relationships, infrastructure, intellectualproperty, information technology, partnerships, processes, productionequipment, vendors, vendor relationships and combinations thereof.